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BACKGROUND OF THE INVENTION 

1 5 Today, portable consumer electronic devices are more powerful than ever. For 

example, small, portable music playback devices can store hundreds, even thousands, of 
compressed songs and can play back the songs at high quality. With the capacity for so many 
songs, a playback device can store many songs from different albums, artists, styles of music, 
etc. 

20 Music jukeboxes implemented in software executed by a digital computer and 

portable MP3 and CD players both provide facilities for forming playlists. For example, the 
OOZIC player, distributed by the assignee of the present application, runs on a host PC and has 
a playlist feature that allows selection of tracks from the PC's hard disk to be included in the 
playlist. 

25 As storage capacity increases and songs are compressed to shorter file lengths the 

number of songs that can be stored increases rapidly. Major problems facing the consumer are 

organizing and accessing the tracks. 

Typically, portable devices have a user interface including a small screen and 

buttons. Such a display screen might be, e.g., 1" x 2". This small display size is necessary 
30 because of the physical size of the device which is typically carried in the hand. The small size 

also limits the number, size, shape, and types of user input controls that can be mounted on the 
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device. For example, a few pushbuttons are usually provided to perform all of the device's 
control functions. Using such a compact user interface to navigate and select among hundreds of 
songs is inefficient and often frustrating. The display screen can only show a few song titles at 
one time, and the limited controls make it difficult for a user to arbitrarily select, or move among, 
5 the songs. 

The creation of playlists is one technique to organize the playing of songs. A set 
of songs can be included in a playlist which is given a name and stored. When the playlist is 
accessed, the set of songs can be played utilizing various formats such as sequential play or 
shuffle. 

10 However, the creation of playlists itself becomes problematic as the number of 

songs increases, since the user often arbitrarily selects songs from a large number of tracks to 
form a playlist. This selection mechanism: can be fairly tedious; does not necessarily produce 
playlists that areof interest to the user over the course of time; may not remain up-to-date if new 
songs are added that logically fit into a previously created playlist (e.g. "Favorites by Band X" 

15 might become out of date if a new favorite by Band X is added after the playlist was created); 
and leads to "lost" songs that are not members of any playlist. 

Accordingly, improved techniques for organizing and grouping tracks useful in a 
portable music player are needed. Further, it is desirable to provide a user interface suitable for a 
small device. The user interface should allow a user to efficiently navigate among, and select 

20 from, many items stored in the device. 

SUMMARY OF THE INVENTION 

The present invention provides an efficient user interface for a small portable music player. The 

25 invention is suitable for use with a limited display area and small number of controls to allow a 
user to efficiently and intuitively navigate among, and select, songs to be played. By using the 
invention, very large numbers of songs can be easily accessed and played. 

One aspect of the invention includes an overlapping hierarchy of categories. 
Categories include items that can also be included in other categories so that the categories 

30 "overlap" with each other. Thus, a song title can be accessed in multiple different ways by 

starting with different categories. For example, a preferred embodiment of the invention uses the 
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top-level categories "Albums", "Artists", "Genres" (or styles), and "Play Lists". Within the 
Albums category are names of different albums of songs stored in the device. Within each 
album are the album tracks, or songs, associated with that album. Similarly, the Artists category 
includes names of artists which are, in turn, associated with their albums and songs. The Genre 
5 category includes types of categories of music such as "Rock", "Hip Hop", "Rap", "Easy 
Listening", etc. Within these sub-categories are found associated songs. Finally, the "Play 
Lists" category includes collections of albums and/or songs which are typically defined by the 
user. 

Advantageous use is made of the overlapping hierarchy to allow the user to 
10 quickly designate a song for playback. The device uses three "soft" pushbuttons that have 

assignable functions. The interface maintains consistent button functionality whenever possible 
and uses uniform command names and operations on different types of items so that the interface 
is more intuitive. For example, the user can open and queue both albums and songs with 
predictable results. 

15 The interface also provides for multiple functions for a single control. For 

example, a "Play" button can act, in a first function, to play a currently-selected song. The Play 
button can act, in a second function, to cycle through different playback modes. The modes can 
be, e.g., (1) playback of songs from a hard disk; (2) playback of music from a radio receiver built 
into the device; and (3) playback of voice messages. The first function for the Play button can be 

20 activated by momentarily depressing the Play button for a short period of time. The second 
function is invoked by depressing the Play button for a longer period of time whereupon the 
device cycles through the different modes. Other ways of invoking the functions are possible 
such as where the second function is automatically entered from a powered-down state. 

In one embodiment, the invention provides a method for selecting songs to be 

25 played in an electronic audio device, wherein the device includes a display and one or more user 
input controls, wherein songs are organized into categories, albums, wherein songs and albums 
are associated with artist names. The method includes steps of displaying categories on the 
display; accepting signals from a user input control to select a category; displaying one or more 
songs in the selected category on the display; accepting signals from a user input control to select 

30 a displayed song; and entering selected songs into a playlist queue, wherein the device plays 
back songs in the playlist queue. 
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According to one aspect of the present invention, a technique is provided for 
organizing tracks on a portable music player by automatically filing tracks in a hierarchical order 
based on attributes of the tracks. 

According to another aspect of the invention, metadata is associated with each 
5 track that is used to automatically define the track's appropriate place in the hierarchy. 

According to another aspect of the invention, the hierarchy is displayed on the 
portable music player so that a user can traverse the organizational hierarchy to find individual 
tracks or find playlists composed of logical groups of tracks. 

According to another aspect of the invention, the hierarchy is derived by using 
10 metadata associated with the audio content that was obtained through any source of metadata 
(e.g. CDDB metadata, id3v2 metadata, other obtainable metadata) and subsequently stored with 
or alongside the file that stores the track. 

According to another aspect of the invention, a file is formatted so that an 
unaltered track is stored as file data and information about the track is stored in file attribute 
15 files. 

Other features and advantages of the invention will be apparent in view of the 
following detailed description and appended drawings. 



20 BRIEF DESCRIPTION OF THE DRAWINGS 

Fig. 1 is a schematic diagram of a tree structure for hierarchical filing of tracks; 

Fig. 2 is a definition file that specifies the hierarchy depicted in Fig. 1 ; 
Fig. 3 is a user's view of the hierarchy; 

Fig. 4 is a schematic diagram of a user interface displaying the hierarchical 
25 category structure; 

Fig. 5 is a diagram of a file format for storing filed data and file attributes; 

Fig. 6 is a flow chart depicting steps for filing tracks according to the hierarchical 

tree structure; 

Fig. 7 depicts a tree resulting from searching the tracks; aa4 
30 Fig. 8 depicts a format for a user interface[[.]]; 

Fig. 9 illustrates the NOMAD Jukebox and its user interface controls; 
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Fig. 10 illustrates a sequence of display screens describing how to navigate to 

lower levels; 

Fig. 1 1 illustrates associations among items; 

Fig. 12 shows display screens used to search for a song or other item; 
5 Fig. 13 illustrates details of different items; and 

Fig. 14 illustrates a playback device coupled to a host computer system. 
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DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

A preferred embodiment of the invention will now be described in the context of a 

portable personal player that plays audio files stored in memory. The files may be in MP3, wav. 
or other digital formats. 

5 In the presently described embodiment, users are able to see the tracks on their 

player in some organized fashion other than as a single list of tracks. As will be described in 
more detail below, in one embodiment tracks are sorted utilizing a tree structure having branches 
labeled according to types of metadata associated with the tracks 

For example, a track recorded as "Golden Slumbers" by the Beatles that appears 
10 on their album "Hey Jude" might appear as a track under the album "Abbey Road" as well as a 
track under the list of tracks by the Beatles. It might appear as a track under the genre "Pop 
Rock" as well as "Songs from the 60' s." Furthermore, the organization can have more complex 
hierarchies. For example, the category of "Pop Rock" might contain subcategories "British 
Musicians," "American Musicians" and "Other Musicians". In all cases, the track is 
15 automatically filed into all appropriate locations without requiring user interaction. 

In the currently defined embodiment, a tree structure is defined by a file having 
the following structure. 

The first line of a TreeDef.inf file contains a version number: 

V1.0 

20 Each subsequent line (at least in vl .0) contains lines of the following format: 

CATEGORY_NAME|TRACK_TYPE_MASK|CATEGORY_STRUCTURE 

CATEGORY NAMEs are the top-level names of the branch under which tracks 
are sorted. They include things like "Album," "Artist," "Voice Tracks," "All Tracks," etc. 

TRACKTYPEMASKs tell which types of tracks are to be filed under this 
25 particular branch. The actual value is a hexadecimal numerical value (in 'Ox' format, e.g. 0x01) 
generated by ORing the following flags together as appropriate: 



enum tTrackType 

{ 

30 kTTNothing=0x00, 
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kTTSong=0x01, 
kTTVoice=0x02, 
kTTBook=0x04, 
kTTMacro=0x08, 
5 kTTPlaylist=OxlO 

}; 

So, for example, the "Album" branch has a TRACK_TYPE_MASK of kTTSong, 
because only songs are filed under that branch, but the "All Tracks" branch has a 
1 0 TRACK TYPE MASK of (kTTSong | kTTVoice | kTTBook). 

Other elements might be added to tTrackType (e.g. kTTVideo) as appropriate. 

CATEGORY_STRUCTUREs tell how to file the songs based on their metadata 
information. The CATEGORYSTRUCTURE is a string of characters that tell, from left to 
right, the order of hierarchy. The characters come from the following enum constants: 

15 

enum tFileTag 

{ 

kFTNone='@*, 

kFTTrackType=T, 
20 kFTTitle^', 

kFTAudioFile='F, 

kFTArtist='M', 

kFTAlbum-L', 

kFTGenre='G*, 
25 kFTSource=*S', 

kFTYear='Y', 

kFTArtistCountry='C 

}; 

30 Thus, a CATEGORY STRUCTURE of LN tells to create a subcategory that is a 

list of Albums, each of which contains a list of Tracks. 
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In total, a line like: 
Album|0x01|LN 

Says to create a branch called "Album" which contains tracks of type kTTSong 
organized first by album name, and then by track name. 

The following is an example of a tree definition file similar (though not identical) 
to the hierarchy presented in the Nomad Jukebox product (the 6 B' before each FileTag was used 
to identify that these are basic tags so that we wouldn't run out of letters in the alphabet as we 
included more complex metadata - thus each group of two letters represents a level in the 
hierarchy): 



V1.0 

Album|0x01|BLBN 
Artist|0x01|BMBN 
Genre|0x01|BGBN 
1 5 Voice Tracks|0x02|BSBGBN 

Playlists|0xl0|BN 
Macros|0x08|BN 
All Tracks|0x07|BN 

20 Fig. 1 depicts a hypothetical organization hierarchy. The tree shows how tracks 

might be listed (as leaves in the tree) after having been organized. Example values for nodes in 
the tree are shown as well. The same track may appear more than once as a leaf in the tree, as 
described above, if it fits into multiple categories (e.g. a song that appears on the Abbey Road 
branch would also appear in the Beatles branch). In the example shown, the first branch contains 

25 tracks organized by album. As shown in the example, this music collection contains three tracks 
from "Abbey Road" and three tracks from "Hits from the 60 Y\ The second branch contains 
tracks organized by artist, and sub organized by where the artist is from. Thus, a user browsing 
would first select the "Artists" branch and then choose between "British Artists" and "American 
Artists". Finally, they would select the particular artist. In the third branch, all tracks are shown. 

30 The tree definition file that would specify the hierarchy shown in Figure 1 is 

shown in Figure 2. 
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The first line identifies the version of the tree definition file. 

The second line defines the "Albums" branch. The first part of the line, 
"Albums" defines the name of the branch. The second part, "0x01," defines that all musical 
tracks should be categorized on this branch. The third part, "BLBN," defines that the branch 
5 lists first the names of all albums (BL) and then tracks on those albums (BN). 

The third line defines the "Artists" branch. The first part of the line "Artists" 
defines the name of the branch. The second part, "0x01," defines that all musical tracks should 
be categorized on this branch. The third part, "BCBMBN," defines that the branch lists first the 
names of all countries where artists in this collection come from (BC) and under those items, the 
10 artists' names (BM), and then tracks by those artists (BN). 

Fig. 3 shows what a user's view of this hierarchy might be if he/she were shown a 
fully expanded view of the 6-song tree. Notice that each song appears three times, once in each 
branch. 

In consumer products the tree define file is not edited directly but through a user 
15 interface, one example of which is depicted in Fig. 4. An example of a user interface for viewing 
songs by category and editing the tree structure is depicted in Fig. 4. 

An embodiment of the invention is utilized in the Nomad® Jukebox, 
manufactured by the assignee of the present invention, and described more fully in the copending 
application, filed on the same date as the present application, entitled "System for Selecting and 
20 Playing Songs in a Playback Device with a Limited User Interface," (Attny. Docket No. 17002- 
020800). 

In a preferred embodiment, metadata is associated with each track and includes 
such information as title, genre, artist name, type, etc. In the preferred embodiment, software 
stored in a portable player and executed by the onboard processor automatically files each track 

25 in the correct category utilizing the associated metadata and the tree define file. The program 
code can be stored in any computer readable medium including magnetic storage, CD ROM, 
optical media, or digital data encoded on an electromagnetic signal. 

Thus, the user is automatically provided with a powerful and flexible tool for 
organizing and categorizing the tracks stored on the portable player. 

30 If the tracks are formatted in MP3 format the metadata can be stored in ID3 tags 

included in the MP3 file. In one embodiment of the invention, the tracks are stored in alternate 
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file format including file data and file attributes. The file data is the music track itself and the 
file attributes part of the file includes fields of arbitrary size which are used to store metadata 
characterizing the track stored as the file data. Again this metadata includes information about 
the track such as title, genre, artist name, type, etc. 
5 There are several advantages to using the alternate file format. Metadata of types 

not easily included in an ID3 tag can be utilized. Further, the original track format is not 
changed, so that error correction data such as checksums are valid. Finally, any file format can 
be used (e.g. WAV, WMA, etc.) because the metadata is stored separately, and thus audio 
formats that have limited support for metadata can still be stored on the portable player in native 
10 format without transcoding. The formatted files are formed by software stored in the portable 
music player and executed by an on-board processor. 

The metadata for each track is utilized to file each track, using the categories 
defined in the hierarchical structure as described above, without any input from the user. 

Fig. 5 is a schematic diagram of the alternative file format including file data in 
15 the form of an MP3 track, and metadata fields for holding data indicating the name of the album 
the track is from, the name of the song, the genre of the song, and the type of track. 

A particular embodiment of a file format will now be described. All tracks are 
created with some set of attributes as shown below: 

20 Definition of Tracklnfo Data Field ' 



Field 


Offset 


Size 


Description 


Attribute Count 


0 


2 


The number of attribute follow for the track 


Attr 1 type 


2 • 


2 


Binary = 0, ASCII = 1 


Attr 1 name len 


4 


2 


Length of attribute name string 


Attrl data len - 


6 


4 


Length of attribute data 


Attrl Name 


10 


N 


Attribute name string 


Attr 1 Data 


10+N 


M 


Attribute data 
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Attr N type 








Attr 1 name len 








Attrl data len 








Attrl Name 








Attr 1 Data 









Required Attributes 



Attribute Name 


Value(s) 


Remarks 


TITLE 


ASCII string 


Required Bv Jukebox 


CODEC 


"MP3", "WMA", "WAV" 


Required Bv Jukebox 


TRACK ID 


DWORD 


Set By Jukebox 


ALBUM 


ASCII string 


Optional 


ARTIST 


ASCII string 


Optional 


GENRE 


ASCII string 


Optional 


LENGTH 


In seconds 


Optional 


TRACK SIZE 


In bytes 


Optional 


TRACK NUM 


1-n (track within album) 


Optional 



These attributes can be subsequently changeable via a host application, 
5 running on a personal computer connected to the portable music player. 

Fig. 6 shows a flow chart of an embodiment the process used to build the 
hierarchical database of tracks. It starts by iterating through each track, and, for each track, 
iterating through each branch to find if the track belongs on the branch, and, if so, where. In this 
case, the term track could refer to any content, e.g. a music track, a spoken word track, or even a 
10 video track. 
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Also, the hierarchical catalog of tracks can be used to form playlists in a 
structured manner. For example, if a user wants to hear Jazz and Blues the entire sub-categories 
can be selected to form one playlist 

An alternative hierarchical catalog generation technique will now be described. 
5 In this alternative embodiment, at system startup and as tracks are added or changed, the 

hierarchy is generated as an in-memory tree structure. Each track is added to the tree using the 
categories ALBUM, ARTIST and GENRE. 

The following example shows the algorithm for adding a track. For clarity, only 
the attributes used by the tree are shown. 

10 



TITLE 


"Free Falling" 


ALBUM 


"Full Moon Fever" 


ARTIST 


"Tom Petty" 


GENRE 


"Rock" 


TRACK NUM 


1 



The following function is executed to build the in-memory memory tree. 

Build Tree () 
1 5 For each track, 

Add Track To Category( Album, Track) 
Add Track To Category( Artist, Track) 
Add Track To Category(Genre,Track) 
End of Build Tree 

20 

Fig. 7 depicts a tree which could result from implementing Build Tree() function. 
Note that "Stardust" does not have any entries for Album or Artist. The host software running 
on a computer connected to the portable music player could be utilized to add missing attributes 
to the "Stardust" track and, optionally, edit the title attribute. The Build Tree() function would 
25 then reinsert this track in the correct location in the tree. 
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Fig. 8 is an embodiment of a user interface according to another embodiment of 
the invention. In this example the root node is labeled "My Configuration" and the Playlist 
category has been selected and the Playlist subcategory "Meddle" has been selected. Note that 
the types of Metadata, in this example, Track Name, Artist, Album, Tempo and 
5 Dance, are listed across the top of the screen, and the attribute values for each track are listed in a 
row across the screen. Various control buttons are displayed to the right of configuration 
window that facilitate quickly invoking selected processing on a selected track. 

As noted above, a preferred embodiment of the present invention is incorporated 
into a product manufactured and distributed by Creative Technology, Ltd. The product is called 
10 the "NOMAD Jukebox." The following description describes further details of the display 
screens and interface controls. 

Fig. 9 illustrates the NOMAD Jukebox and its user interface controls. 

In Fig. 9, electronic audio device 100 measures about 5.5" wide by 5.5" tall by 1" 
thick. Display screen 102 is about 2" wide by 1" tall. Display screen 102 includes different 
15 regions such as main region 104 and soft button function description region 106. 

Three soft buttons are located at 108; including buttons 110, 112 and 1 14. The 
specific command, or function, that any of the soft buttons perform when depressed is indicated 
by the label in soft button function description region 106. Thus, the function of soft button 1 12 
(as shown in Fig. 9) is "open," the function of soft button 1 14 is "search" while soft button 1 10 is 
20 currently not assigned a function. 

The other eight buttons on device 100 perform essentially the same functions at 
all times. In other words, they are not subject to function changes according to soft button 
function description area 106. These buttons include Library button 1 16, EAX and System 
button 118, Skip Backward button 120, Play button 122, Stop button 124, Skip Forward button 
25 126, Scroll Up button 128 and Scroll Down button 130. However, as discussed below, these 
buttons (or any type of controls used with the device) can include alternate functionality that is 
invoked in different ways. 

The device uses visual cues, or indicators, in the display. When an item is 
highlighted it indicates that the item is the "current" item, or currently-selected item, which is 
30 susceptible to be operated on by a subsequent user action - such as playback, or expansion of the 
item. In Fig. 1, screen 102 shows that the item, "ALBUMS," is highlighted. The highlighted 
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item can be acted upon by using the soft buttons, or another button, as discussed below. The 
current item can be changed by using Scroll Up button 128 and Scroll Down button 130 to move 
the highlight up or down, respectively, throughout a list of displayed items. 

Icons are used to provide additional visual cues for an item. In Fig. 1, each of the 
5 categories has a category icon to the left of it. The category icon, which may not be distinctly 
visible in the Figure, illustrates a first box connected by lines to additional boxes below the first 
box. The icon depicts a hierarchy and illustrates the property of categories, i.e., that categories 
can contain additional categories, songs or other items. 

Fig. 1 0 illustrates a sequence of display screens describing how to navigate to 

10 lower levels. 

In Fig. 10, library category screen 150 shows the display as it appears when the 
user depresses library button 116 of Fig. 9. A preferred embodiment of the device uses 4 first- 
level categories. These are "Albums", "Artists," "Styles" and "Play Lists". Each of these 
categories can "contain," or be associated with, other categories, songs, or items. 
15 Note that in library category screen 150 ALBUMS is currently highlighted. By 

de pressing soft button 1 12 of Fig. 9, the "open" command is performed on the highlighted 
category, as indicated by the labeling of soft button 1 12 and soft button function description area 
152 of Fig. 10. 

Lists screen 154 is displayed as a result of a user opening the Albums category of 
20 library category screen 150. Lists screen 154 shows items within the Albums category such as 
commercial albums of multiple songs from a record label, pre-made lists or collections created 
by a user, or other predefined lists or collections of songs or recordings. 

In Fig. 10, lists screen 154 shows each item as a list of songs. This is shown 
visually by the icon to the left of each item which depicts a miniature list. Possible soft button 
25 commands are "Close", "Open" and "Queue". These commands correspond to soft buttons 110, 
1 12 and 114, respectively. If the user selects the Close command, the display reverts to library 
category screen 150. If the user selects the Open command, the display shows tracks screen 156. 
Alternatively, the user can select the Queue command to instruct the device to place all the songs 
from the selected (i.e., highlighted) list into the play list for eventual playback. Yet another 
30 option allows the user to press play button 122 of Fig. 9 to cause any currently-selected songs or 
a list of songs (e.g., an album) to immediately be played. 
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Returning to Fig. 10, tracks screen 156 shows that a single song called "JukeBox 
Demo" is in the list. The list is also called JukeBox Demo as shown in lists screen 154. Tracks 
screen 156 shows possible soft commands assigned to buttons, namely "Close", "Details" and 
"Queue." The Close button performs the same function as before — it returns the user to the 
previous screen which, in this case, is lists screen 154. The user can also select the Details 
command to cause details of the song JukeBox Demo to be displayed in details screen 158 as 
shown in Fig. 10. The user can select the Queue command by soft button 1 14 to enter the 
selected song into the play list queue. As before, the user can also depress play button 122 of 
Fig. 9 to cause immediate playback of the selected song. 

Details screen 158 shows information about the selected song including the name 
of the song, album (or list) name containing the song; the track number, if applicable, and track 
duration. Note that other information can be included. The user can preview the song, close the 
Details screen to return to the Tracks screen or queue the song on the play list queue. 

The device provides the ability to "preview" audio files even while a current song, 
or playlist, is being^played. When a user chooses to preview an audio file, the audio file is 
played for about 10 seconds while any currently-played file or playlist is suspended. After 
previewing is complete, the suspended file or playlist resumes playback. In other embodiment 
the preview duration can vary, or be stopped by user selection. 

Fig. 1 1 illustrates associations among items. 

In Fig. 11, song 168 is one of many songs stored in the device. Categories such as 
albums 160, artists 162, play lists 164 and genres 166 each include sub-categories. For example, 
albums 1 60 includes the names of various albums. Songs are associated with albums, genres and 
playlists. Such association can be by using pointers, a data structure including items to be 
associated, etc. "Association" as used herein, includes a first item associated with a second item; 
and the second item associated with the first item. In other words, albums can be associated with 
one or more songs in the database of the device so that an automated search to find all songs 
associated with an album is easier. The direction of arrow pointers in Fig. 1 1 is not intended to 
limit the manner of associations among items in the present invention. 

Similar to albums, the category of artists 162 includes names of artists, or 
performers, of songs. Each artist name is associated with one or more songs in the database. 
Playlists 164 includes names of playlists. These are collections of songs that can be defined by 

15 



f 

4 



the user, the device manufacturer, or others. Each playlist can be associated with one or more 
songs. Genres 166 includes various styles of music which are associated with one or more songs 
in the database. Note that items can exist without being associated with a song. Also, items can 
be associated with other items as where an artist name is associated with the albums containing 
5 the songs that the artist has created. 

Although not shown in Fig. 1 1, items can have additional information, such as 
properties, details, etc., associated with the item. For example, a song can have information such 
as play time, artist name, artist album, copyright owner, etc., associated with the song. 

Fig. 12 illustrates display screens used to search for a song or other item. 
10 In Fig. 12, screen 180 is the initial library screen, as discussed above. If the user 

invokes the Search command (Via the appropriate soft button) with Albums selected then screen 
1 82 is displayed. Note that the search function can be applied to any of the categories. The user 
can depress the Plus or Minus soft buttons to cycle through the alphabet and change the character 
in the current location as indicated by the cursor. The cursor position is changed by using the 
15 scroll up/scroll down buttons 128 and 130, respectively, of Fig. 9. As each letter is entered the 
letters are compared and the nearest match of the stored albums' names is displayed as shown in 
screen 184. When the desired match is displayed the user selects the Go! command. 

Screen 186 shows the result of selecting the Go! command. A list of albums is 
displayed with the matched album centered and selected. The user can close, open or queue the 
20 album as discussed above. 

Fig. 13 illustrates details of different items. 

In Fig. 13, screen 200 illustrates details displayed as a result of selecting the 
"Details" command from soft button 1 A track is selected. Screen 200 shows that details of the 
track "Jukebox Demo" shows the name of the album that the track resides on, the creator, or 
25 copyright owner, of the track, and the playing time of the track. 

Screen 202 illustrates details of an item on the active queue list. Items are placed 
onto the active queue list by selecting the "Queue" command when an album, song, track, or 
other item is selected, as discussed above. For example, screen 204 shows the active queuelist 
where the track "Jukebox Demo" is selected. By invoking the "Details" command screen 202 is 
30 brought up to show details of the Jukebox Demo track. 
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As shown in screen 202, the Detail screen shows what track number the selected 
track is, which album the track is from; the creator, or copyright owner, of the track, and the title 
of the track. Additionally, the details for an item on the queue list also show playback settings. 
These are shown by two-letter abbreviations at the bottom of the screen. The settings are as 
5 show in Table I, below. 



EA 


Environmental Preset 


EQ 


Parametric EO 


HS 


Headphone Spatialization 




IS 


Time Scaling 


4S 


Four Channel Speaker Sound 


(only if speakers are connected) 





TABLE I 
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These settings have their common meanings, as is known in the art. Note that the 
setting 4S is not shown in screen 202 as it is not currently active. 

Fig. 14 illustrates the Nomad Jukebox coupled to a host computer system. 

In Fig. 14, device 300 (e.g., the Nomad Jukebox) is coupled to host system 302. 
5 In a preferred embodiment host system 302 is a personal computer, such as an IBM-PC 

compatible computer. Host system 302 includes a user interface having display 304 and user 
input devices such as keyboard 306 and mouse 308. In other embodiments the host system need 
not be a full computer system. Any type of processing system having a user interface is possible. 
For example, it is possible to couple the device to a laptop computer, game console, web-enabled 
10 television, or any consumer electronic device or digital platform, in general. The host user 
interface need not provide a display and can be much more minimal than the keyboard and 
mouse shown in Fig. 14. A preferred embodiment of the invention uses a Universal 
Synchronous Bus (USB) connection but any type of connection such as IEEE 1394 (Fire Wire), 
Ethernet, Serial Port, etc. can be used. A wireless (i.e., optical or radio frequency) connection 
15 can be used. 

Once device 300 is coupled to host system 302, a user of host system 302 can 
launch a bridge interface to allow for the transfer of files between device 300 and host system 
302. In a preferred embodiment, once the bridge interface is launched, the controls of device 
300 are inoperable. The user interface of host system 302 is used to operate the bridge interface 
20 to transfer files. 



The invention has now been described with reference to the preferred 
embodiments. Alternatives and substitutions will now be apparent to persons of skill in the art. 
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